Overview

Intrusion Detection Systems (IDS) are rule-based security controls designed to monitor a system or network for suspicious activity. When suspicious activity is detected, an IDS will generate alerts to the system administrator. Most IDS solutions are also capable of functioning as Intrusion Prevention Systems (IPS), which will actively block the suspicious activity, rather than simply report it. In practice, IDS/IPS's are typically configured to send their alerts to Security Information and Event Management (SIEM) systems, which aggregate security alerts from multiple systems in a centralized interface that security analysts can easily monitor.

There are two types of IDS/IPS - network-based IDS/IPS (NIDS/NIPS) and host-based IDS/IPS (HIDS/HIPS). As the name implies, an HIDS/HIPS is designed to monitor a single host, while an NIDS/NIPS is designed to monitor an entire network. NIDS/NIPS are typically integrated with modern firewalls, where they can easily monitor all traffic that passes through the firewall. It is also common for an IDS to have a primary server in one central location and multiple sensors in other subnets that then forward findings to the primary server.

The two most popular NIDS/NIPS solutions are Snort and Suricata. Both packages can be installed on stand-alone Linux systems and are integrated into popular firewalls like pfSense, Smoothwall, and OPNsense. Both Snort and Suricata use the same kind of rules (called signatures), are multithreaded for performance and resilience, and can operate in different modes (intrusion detection, logging, and sniffer). The focus of this lab will be on Snort.

Snort Rules

Snort rules can look a little strange at first, but the basic syntax is pretty straightforward. A Snort rule is made up of a header section and an options section. The header section reads a bit like a firewall rule, and the options section can be as simple as a message and a sid (a unique identifier).

Header: alert tcp 10.10.10.1 any -> 10.10.10.100 21 / Options: (msg: "User has accessed FTP"; sid: 00001;)

In the example above, Snort will alert when host 10.10.10.1 (the source) tries to touch TCP port 21 on host 10.10.10.100 (the destination). The source is always on the left and the destination on the right. Notice the -> which is the flow indication (from source to destination). The sid (Snort ID) can be any numeric value, but all sids in a rule file must be unique. The message (msg) is simply what gets logged when this alert happens. You can write any message you like, but it should be related to the traffic rule to be useful.

In Snort, rules often look in both directions:

Header: alert tcp any any -> any 25 / Options: (msg: "SMTP Detected"; sid: 00002;)
Header: alert tcp any 25 <> any any / Options: (msg: "SMTP Detected"; sid: 00003;)

In the above example, Snort will detect TCP 25 (typically used for SMTP messages) from any source to any destination, and then from any destination to any source. Notice there is no <- flow indication; <> is used to indicate both directions.

Snort is also capable of reading the contents of a packet and sending alerts if a matching pattern is found:

alert tcp any any -> any any (msg: "Botnet Detected"; content: "|5a 4f 4f 4d 00 00|; sid: 00002

In the example above, we are using the content option to find the hex string "5a 4f 4f 4d 00 00" in any TCP traffic. This string's presence indicates that the Zeus botnet exists on your network. If you have seen production class Snort rules in the past, then you know the options section can get pretty involved. There are a lot of options and many different ways to use them. Even security experts don't always agree on the "best" way to hunt for a given evil using the options syntax. With that in mind, we will keep the options used in this lab fairly simple for learning purposes.

In the next steps, you will start Snort from the command line and acquaint yourself with its interface. If you haven't already, click the Start Lab button to launch the lab environment.

1. On the dock at the bottom of the screen, click the Terminal Emulator icon to open a Terminal window.
   
2. At the cybrary@snort prompt, type sudo snort and press Enter to start Snort.
   
   You will see live packet captures in progress - mostly to TCP port 3389, because this remote lab environment is accessed using RDP.
   
   By default, Snort will start in sniffer mode, where it will behave much like the tcpdump command line packet capturing tool.
   

   

   In the screenshot above, we see that 10.1.30.251 is accessing 10.1.30.37 over TCP 3389. Your output will differ, but it should be just as readable as the sample shown. The warning shown simply means that Snort wasn't given a config file (more on config files to come).
3. Press CTRL-C to shut down Snort, then take note of all the information Snort tells us about the network traffic it captured, including the following:
   
   Packets Captured

   

   Packets Analyzed vs. Packets Dropped

   

   A full protocol breakdown

   

4. At the cybrary@snort prompt, type clear and press Enter to clear the contents of the open Terminal window.
   
5. At the command prompt, type sudo snort -T -c /etc/snort/snort.conf and press Enter to validate the configuration file.
   
   By default, Snort keeps a working configuration file (snort.conf) in the /etc/snort directory on Linux systems.
   
   The -T option means "test" and the -c option tells Snort where to find its configuration file. This will test if the default configuration file is in good shape. A lot of text will scroll by, but you are looking for the following output:
   
   "Snort successfully validated the configuration! Snort exiting"
   
6. At the cybrary@snort prompt, type sudo snort -c /etc/snort/snort.conf and press Enter to start Snort.
   
   You will notice that after some initial scrolling, the screen stops at "Commencing packet processing". When you pass Snort a configuration file (-c), Snort runs in intrusion detection mode. In intrusion detection mode, Snort compares all traffic captured against a large base of rules (found in /etc/Snort/rules). Because this is an isolated lab environment, we don’t expect there to be a lot of traffic - let alone malicious or suspicious traffic.
   

   

7. Press CTRL-C to stop Snort.
   
   Notice again that Snort prints out a lot of information about what it saw while it was running. When Snort runs in intrusion detection mode, you will see additional statistics on actions like alerts, packets logged, and packets passed.
   

   

   Note: If you run Snort in intrusion detection mode on your home network, you may find a lot of alerts. Most (maybe all) of these will not be real attacks. Like any NIDS/NIPS, Snort needs to be tuned to reduce noise and false positives.
8. At the cybrary@snort prompt, type cd /home/cybrary/Desktop and press Enter to change your current directory to the Desktop.
   
   Snort is capable of reading packet capture files, just like tcpdump and Wireshark. In the next steps, we will use Snort to analyze a pcap file.
   
9. At the cybrary@snort prompt, type sudo snort -c /etc/snort/snort.conf -r sample.pcap and press Enter to instruct Snort to analyze the pcap file on the desktop as if the traffic was running live.
   
   Notice there were a few alerts in this pcap file:
   

   

   By default, Snort will send its output to the screen. However, Snort can also be set to logging mode. In logging mode, Snort sends all output to a number of log files instead.
10. At the cybrary@snort prompt, type sudo snort -c /etc/snort/snort.conf -r sample.pcap -l /home/cybrary/Desktop and press Enter to run Snort in logging mode.
    
    The -l switch tells Snort to save its logs in the directory given. In this case, we are saving the logs to the Desktop. You will see three log files: snort.alert.fast, snort.log, and snort.alert.
    
11. On the Desktop, double-click the snort.alert.fast file to open it in Mousepad.
    

    

    Notice the alerts are from November 2019, which is when the pcap was made.
    
    When you are finished, close the Snort.alert.fast file. If prompted, close without saving.
    
    You will not be able to open the Snort.log or Snort.alert files in Mousepad or any other text editor, as they are written in "unified2" format by default. Instead, we need a special tool: u2spewfoo.
    
12. At the cybrary@snort prompt, type sudo u2spewfoo snort.log and press Enter to read the Snort.log file using u2spewfoo.
    
    You can also use | more or | less to pause the output (for example, sudo u2spewfoo Snort.log | less).
    
    Scroll up to review the complete output, and notice that each log is made up of the Event…
    

    

    …and the Packet:

    

    Note: There is only an event if Snort detects a rule violation, otherwise there will only be a packet.